VAST 2012 Challenge
Mini-Challenge 2:

Team Members:

Daniel-Ionut Paval, University of Konstanz, dannyel_ionut@yahoo.com

Jan Hildenbrand, University of Konstanz, jan.hildenbrand@uni-konstanz.de PRIMARY

Prakash Thapa, University of Konstanz, prakash.thapa@uni-konstanz.de

Student Team: Yes.

Tool(s):

KNIME: Konstanz Information Miner [http://www.knime.org/] is a user-friendly and comprehensive open-source data integration, processing, analysis, and exploration platform.

As part of the exploration of the data we developed our own tool which operated with a MySQL [www.mysql.com] database where the data was stored.

We used Tableau [www.tableausoftware.com] to do a detailed visualization and analysis of the events.

Video:

KNMC2 submission

Answers to Mini-Challenge 2 Questions:

MC 2.1 Using your visual analytics tools, can you identify what noteworthy events took place for the time period covered in the firewall and IDS logs? Provide screen shots of your visual analytics tools that highlight the five most noteworthy events of security concern, along with explanations of each event.

In the Fig 1 we show an overview of the important moments in the logged time frame. We will present further the events that happened at that points in time.

Fig 1. Important moments in time, were suspicious activities were spotted

Noteworthy Event 1: First policy Violation (IRC auth. Message) . Fig 2

2.5 Hours after the beginning of the logs (on 5^th April, at 20:25), a lot of workstations start numerous outbound connections with 6667 as destination port (Fig. 3a)). This port is normally used for IRC communication, which is against the Bank policy. It’s the first time they appear in one of both Logs. We found it by analyzing the port usage for the whole list of connections and we’ve notice that destination port 80 and 6667 have the biggest share of connections(Fig. 2). On port 80 a lot of connections are very normal, but on port 6667 this is unlikely.

Fig. 2 Overall Number of connections to destination port in whole firewall data set

Fig 3. Plot of the IDS log filtered for “IRC auth. Message” with time as x-axis and number of entries as y-axis.

Noteworthy Event 2: Firewall attack

We have three findings that lead us to the idea that there was an attack on firewall right after midnight of 6^th of April (00:04am). These three events occur in the same time frame.

1) A spike in the amount of SSH connections (Fig 4). A single workstation (172.23.231.69) has 18 connections in one minute that use the destination port 22 (SSH) with the target 172.23.0.1 (the firewall), although none of the connections are successfully build, we searched for more entries for this particular IP. We investigate further for this IP address to make a list of ports used for services that could break the bank policy if used any outbound connections. We didn’t found outbound connection, but we’ve noticed this behaviour.

Fig 4. The firewall attack – The spike of the SSH connection.

2) A similar spike (Fig 5) in the usage of destination port 161 (SNMP) is also at the same time by the same IP 172.23.231.69 and the same destination: The firewall(172.23.0.1). The SNMP is also known as being one of the major threads for the year 2000. http://www.sans.org/top20/2000/

Fig 5. The firewall attack - The spike of the SNMP request

3) Another spike (Fig 6a)) in the amount of connections with the destination port 6667 (related somehow to IRC) particular associated with 172.23.231.* (including 172.23.231.69) and 172.23.235.* as Source IP and 10.32.5.50-59 as Destination IP.

Fig. 6. Plot of the firewall log filtered for destination port 6667

These three findings lead us to the hypothesis, that the workstations with high number of connections to port 6667 are infected with a bot or malware. The bot user probably wanted to attack the firewall with different standard attacks (using for example recovered passwords to connect to the firewall), over IRC commands sent to an infected workstation (probably 172.23.231.69), which executed the commands from the inside. The high amount of connections to port 6667 could be a side effect of the interaction logs and commands sent over IRC.

Noteworthy Event 3: Dropdown

At the beginning of our analysis we just plotted the entire traffic (number of connections per minute) on a time scale and we’ve noticed a clear dropdown (Fig 7) of the traffic on 6^th of April, between 14:24 and 18:05. This event is linked to the next ones.

Fig 7. Traffic dropdown in the second day, from 14:24 to 18:05

Noteworthy Event 4: Increased 6667 traffic /Decreased IRC auth. Messages / FTP Connections

After the dropdown, we found several suspicious things:

1) A spike in the outbound FTP connection number (destination port 21). We found this by looking at the port usage after the dropdown. All of these connections are created by a single IP 172.23.1.168 and are denied by the Firewall.

Fig 8 – the green line

Fig 8. The spike of the green line show the FTP traffic after the dropdown

2) Increased number of outbound connections that uses destination port 6667 (Fig 6c)). In the same time, in the IDS logs the number of “IRC Authorization message” labelled connections are lower than before (Fig 3c)), so we could assume that now the port 6667 is used more for other activities (e.g. sharing data) than before (Fig 6b), Fig 3b)), that is not labelled by the IDS as “IRC Authorization message”.

Noteworthy Event 5: Distributed Denial-of-service (DDoS) attack

A new IP (172.23.252.10), which was not active before, started building TCP connection to this range: 10.32.5.50-59(destination IPs) and it used, incrementally, the entire scale of source ports. It used as the destination port only 80 and 6667 (Fig 9). Since this is the first time this IP appears in one of both logs and it has its own subnet (there are no entries with 172.23.252.* beside the given IP), we could assume that this is a new computer in the network, maybe a laptop brought by an employee, which could be another policy violation. On the other hand, this behaviour (multiple connections from different source ports) is specific for DDOS (Distributed Denial of Service) attacks and we could assume that somebody is using the Bank network to launch this attack. In Fig 8 we could clearly see that starting on 6^th of April, 18:00, this IP is continuously building new connections with bigger source port number than before.

Fig. 9. The source port number increases over the whole time of the activity of 172.23.252.10.

MC 2.2 What security trend is apparent in the firewall and IDS logs over the course of the two days included here? Illustrate the identified trend with an informative and innovative visualization.

The number of possible active infected machines can be shown through the analysis of number of different source IPs which are connecting often to the destination port 6667. We can see clearly that the amount of possible infected machines rises until one hour past the firewall attack (Fig 10a)). It looks like the Bot spread to some higher numbered subnets mostly to 172.23.231-240.* (seen in Fig 11 upper half). That changes after the increase of suspicious activity. The number is nearly double as high as before and also other subnets are infected like 172.23.123-137.* and 172.23.254.* (seen in Fig 11 in the lower half and Fig 10b)).
The destination IPs for the suspicious connections are the whole time 10.32.5.50-59.

Considering the spike in the outbound FTP connection number (destination port 21 Fig. 8), we could assume that there was an attempt of sensitive information exchange, but since the firewall denied this connections, the information started to be transferred thru the IRC connections (destination port 6667 Fig. 6c) and 3c)).

Fig 10, distinct count of source IPs which uses the port 6667 over time.

Fig 11, our own visualization tool, x-axis source IP, y-axis destination IP, every dot is one connection in a 10 minute timeframe starting at the given dates. The colour of each dot scales with the amount of connections. The upper half of the Fig. is located at the time of Fig.10 c) the bottom half of the Fig. is located at the time of Fig. 10.d)

MC 2.3 What do you suspect is (are) the root cause(s) of the events identified in MC 2.1? Understanding that you cannot shut down the corporate network or disconnect it from the internet, what actions should the network administrators take to mitigate the root cause problem(s)?

Judging on the behaviour of the network, we have concluded that there was already some malware before the first firewall and ids logs provided to us. It got active after 8:25pm of 5^th April. Here are some suggestions for network administrator:

1. Implement a network login policy so that all workstations work in the user-mode with limited rights and only specific station would have admin rights.

2. Make a white-list for the ports that are usually used for regular/permitted traffic and block all others, like 6667(IRC).

3. Take one workstation out of network at a time, fix the security vulnerabilities of this station, clean it from malware and insert it again in the network. Now it would be protected from reinfections.

4. No new, automatically IP allocation for unknown MAC addresses. In this way, a laptop brought by an employee could not join the Bank Network without explicit access granting.

5. No software installation rights for the normal users, unless explicitly and temporarily granted. This includes drivers for new USB devices.